koblas

UmfpackSparseLapack

class UmfpackSparseLapack : SparseLapack(source)

The sparse factorization half backed by SuiteSparse's UMFPACK, on the native targets.

Behaviourally identical to the JVM binding, down to the fallbacks: equilibrate and any non-default dropTolerance go to the portable factorization because UMFPACK cannot honor either, a singular result becomes koblas's canonical SingularSparseFactorization, and any UMFPACK failure falls back rather than propagating. The conformance test asserts against the portable factorization on both platforms for exactly that reason — a host backend that answered differently would be a bug wherever it ran.

Registered at 90, the priority the native host backends use, so it wins over SparseLu where SuiteSparse is installed. The JVM bindings use 100 for the same role; the two values only ever compete within one half, so the difference is cosmetic, but the platform's own convention is the one worth matching.

Properties

name

open override val name: String(source)

A short backend identifier for diagnostics (e.g. "reference").

priority

open override val priority: Int(source)

Relative preference among simultaneously available backends: automatic selection through registerBackend — JVM classpath discovery, native startup registration — picks the highest per half. The portable reference is 0; native-accelerated backends rank above it (koblas-openblas 100, koblas-cblas 90).

Functions

factor

open override fun factor(a: SparseMatrix, equilibrate: Boolean = false, dropTolerance: Double = NO_DROP): SparseFactorization(source)

Factorize the square a into something solvable, never null.

A singular matrix comes back as a factorization reporting singular, matching the dense contract where com.eignex.koblas.dense.LuDecomposition carries the flag. There is no nullable result to unwrap and no exception on the ordinary path: a simplex whose basis went singular wants to inspect and repair it, not catch something.

With equilibrate, rows are first scaled by a power of two so pivoting is better conditioned; the scaling is undone transparently in the solves and the determinant.

dropTolerance trades accuracy for sparsity: an entry the elimination produces whose magnitude is below this fraction of the matrix's largest is discarded rather than stored, so the factors stay sparser than the true L·U. The result is then an incomplete factorization — a solve against it is an approximation, not a solve — which is why it defaults to zero and has to be asked for. It is worth asking for when fill is the binding constraint and a residual around the tolerance is acceptable; on a diagonally dominant matrix 1e-9 has been measured cutting fill threefold at a residual of 1e-11 against 1e-15. A backend that cannot honor it must fall back rather than ignore it.